Preksha Saxena

Maze ransomware continues to be a threat to the consumers

June 18, 2020
Estimated reading time: 6 minutes

Maze is a recently highlighted ransomware among the ever-growing list of ransomware families. The ransomware is active from the past one year, although it came into limelight due to its new approach of publishing sensitive data of infected customers publicly.

The malware uses different techniques to gain entry like the use of exploit kits or email impersonation. These phishing emails are having a Word document attachment that contains macros to run the malware in the system.

Maze uses CHA-CHA algorithm for encryption and its key is encrypted using the RSA algorithm. Maze can run with or without mutex —it uses some Russian IPs for the webserver to sends information from the victim system(s). It uses RSA encryption request for CnC communication and it will not encrypt the system for the specific region by checking keyboard type.

Stage – I


The attached document file has a form containing an input box in which the number array of encrypted URL and path is present. The document file contains an ActiveX object. When it is executed, URL and path are decrypted post which it calls URLDownloadToFileA() that downloads an executable to the specified location.

Fig 1. URLDownloadToFileA() Call with their parameters


The number array is read from text box then converted into characters and concatenated to form a URL and path where the file is downloaded. Sometimes it also uses PowerShell to download the file. In most of the cases, file is downloaded at “C:\Windows\temp” location.

Fig 2. Characters stored in Number Array


Stage – II


The first stage of Maze ransomware is custom cryptor. This cryptor is a packed one with few imports. It loads libraries by calling LoadLibrary() and GetProcAddress() from kernel32.dll. In this cryptor, function names are stored with their adler32 checksum.

The cryptor is for anti-debugging, it passes junk strings to the function OutputDebugStringW().

Fig 3. Call to OutputDebugStringW()

In the below code, it checks whether the file is present or not, if present it will terminate. Similarly, it also checks specific command-line arguments if it is present it will change execution flow. Then malware loads the resource where actual DLL is present. The loaded resource is encrypted and XOR operation is used with key 0x41. After decryption, we get base64 encoded data.

Fig 4. Xor Loop and API resolution

After copying all data onto the stack, API names are formed and then it calls Loadlibrary() Win32 API. Then it decodes base64 data by calling CryptStringToBinaryA() API. The decrypted buffer is again decrypted using CHA-CHA 20 algorithm which brings the actual payload of Maze ransomware. Along with payload (which is a DLL of Maze), it also decrypts shellcode. By using CreateThread() API, it executes the shellcode.

Fig 5. Call to CreateThread()

In this payload code, it first loads the base address of kernel32 for PEB. The below code shows the loading of the address.

Fig 6. The address is loaded from PEB

The shellcode allocates memory using VirtualAlloc() and copies DLL file to newly allocated space. Then it creates a thread and executes code from DLL. This code changes bytes at the original entry point and then jump to OEP.


In decrypted payload, it first loads all the APIs and then does patching of dbgUiRemoteBreakin from ntdl.dll. It is one of the anti-debugging techniques it uses to avoid attachment of debugger.

First it calls VirtualProtect() on dbgUiRemoteBreakin with PAGE_EXECUTE_READWRITE as new flNewProtect. Then it replaces byte 6A with C3 by simple mov instruction. So, if someone tries to attach debugger it will get failed.

Fig 7. Copy 0xC3 at dbgUiRemoteBreakin Entry point


Fig 8. Code before and after patching

Then it enumerates running processes using Process32First() and process32Next(). It calls APIs using ‘je’ instruction and address is pushed onto the stack which is executed after API call. The call is replaced with ‘push’ and ‘jz’ or ‘je’ instruction.

Fig 9. Call to Process32NextW () using jz instruction

After process enumeration, it will obfuscate all the names with its algorithm which uses XMM registers. Then it calculates the hash of this obfuscated string which is then compared with some hardcoded hashes. Some of them are:

Procmon64.exe: 0x776E0635

Procexp64.exe: 0x78020640

Ida.exe: 0x33840485

Dumpcap.exe: 0x5FB805C5

X32dbg.exe: 0x5062053

Fig 10: Compare hashes with running process hashes

When any of the process hash matches it calls TerminateProcess() and exits the running process.

It will not encrypt files for specific keyboard type. To get keyboard type it calls the function GetUserDefaultUILanguage(). For eg:

Russsian : 0x419 // NOT Encrypt For this value

Ukrainian : 0x422 // NOT Encrypt For this value

Serbian : 0x7C1A // NOT Encrypt For this value

en_US : 0x409 // Encrypt For this value

Fig 11. Check value return by GetUserDefaultUILanguage()

Then It first communicates with CnC server where the IP list is hardcoded, all below mentioned IP seems to belong to Russia.

Fig 12. Hardcoded Ip list

Then data is sent to CnC on the first request: Data which is sent is Username, Computername, OsVersion.

Malware create mutex with unique ID unique ID is created using SHA(GetComputerName() + VolumeID()) .

For the ransomware marker, it creates a unique file on root and each folder.

Maze Encryption Process:

Malware selects files for encryption based on the extension. It excludes the following extensions:

· Exe

· Dll

· Sys

· lnk

It also excludes the following files:

· Decrypt-Files.txt

· Autorun.inf

· Boot.ini

· Desktop.ini

· Temp/000.bmp

Excluded folders:

%windows%, @gaming%, %programdata%, %tor Brower%, %local Settings%, %appdata% etc

Fig 13. Checking folder names and if the same found it will not encrypt the folder.

Encryption process:

It first creates key and then exports it in the “c:\programdata\data1.tmp” folder. Then it drops a ransom note in each folder before encryption. Later it will just import the key from this file and call “CryptEncrypt()”.

It retrieves drive letters and then determine type of drive using GetDriveType(). Further it enumerates using API calls FindFirstFileA() and FindNextFileA().

It deletes shadow copy by creating a fake path for wmic and then calls delete recover by calling CreateProcessW()It encrypts files using CHA-CHA algorithm and the key of chacha is encrypted using RSA. For this, it uses crypto APIs. Encrypted files are having a marker at the end which is ‘66116166’.

Fig 14. Encrypted File by Maze ransomware

It creates a thread for each drive, which then again call create thread function for each folder which does the encryption. Encryption will start from the root of C: or D: and parallelly it also accesses the shared drive by using WNetShareEnum() API. The same encryption function is used for encrypting shared drive files. The first folder which is encrypted is “$Recycle Bin”.

CreateThread() with following function for each folder. File is opened as follows. File is encrypted by calling CryptEncrypt() and it is renamed by calling moveFileEx() with extension.

Encrypted File:

Fig 15. File After encryption

Maze Malware uses many tactics for anti-Analysis:

  • APIs are resolved at runtime.
  • Indirect calling of API & functions using JE & JNE instructions.
  • Patching DbgUiRemoteTracking to avoid attaching of debugger at runtime.
  • Checking being debugged flag.
  • Checking for VM.
  • Checks RAM & hardware size by using API – GlobalMemoryStatusEx & GetDiskeSpaceW.
  • Check process names by calculating its hashes.

Prevention measures to stay away from ransomware

Common infection vectors used by Maze Ransomware are phishing emails with MS Office attachments and fake/phishing websites laced with Exploit Kits. Hence, we advise our end users to exercise caution while handling emails from unknown sources, downloading MS Office attachments, enabling macros, and clicking on suspicious links.

Indicators of compromise



Subject Matter Expert
Preksha Saxena | Quick Heal Security Labs

Have something to add to this story? Share it in the comments.

Preksha Saxena
About Preksha Saxena
Preksha is a security researcher at Quick Heal Security Labs and has 6 years of experience in the cyber security domain. She is interested in reverse engineering...
Articles by Preksha Saxena »

No Comments, Be The First!

Your email address will not be published.